The present invention relates to verification of electronic hardware designs, and more particularly to a system and method in which an electronic hardware simulator is driven by a user-written test script.
Before any piece of complicated electronic equipment is actually constructed from a new design, it is desirable to verify that the design is correct, that is, to confirm that the design will result in equipment that operates in accordance with predetermined functional specifications. For this purpose, hardware simulators, in the form of computer programs such as Verilog, are known.
In performing design verification, it is frequently necessary to simulate not only the newly designed hardware, but also enough of the surrounding electronic environment to provide suitable interface signals to the circuit under test. For this purpose, the engineer creates or obtains a model of a "master" device (henceforth referred to as a "master model") that can, by way of instructions, manipulate the simulation environment in a desired fashion and produce deterministic results. For example, in order to test a memory chip, an engineer requires a master model to generate functionally and correctly timed read and write control signals to the chip within the simulation environment. The constraints imposed by the instruction set of the master model limit the extent of verification.
Currently, in the Verilog simulation environment and depending on the master model, such instructions take one of four forms: 1) a master model's native assembly language, 2) Verilog Hardware Description Language (HDL), 3) Programming Control Language (PCL) (a language for use with Verilog models of widely used integrated circuits, the models being commercially available from a company called Logic Modeling Corporation), or 4) a user created language using a combination of HDL and Verilog's Programming Language Interface (PLI). The use of these languages will now be briefly described.
If the master model (implemented either in HDL or as a gate level model) emulates a real central processing unit (CPU) to the extent that the modeled CPU not only generates functionally and correctly timed control signals but also executes binary compatible instructions, then the modeled CPU executes those instructions directly from an emulated memory device (also within the simulation environment). These instructions are in the form of the CPU's native assembly language. Consequently, testing a modeled circuit under these circumstances requires, first, that a test scenario be written using the instructions of the "master model" that interfaces with the modeled circuit under test. These instructions must then be assembled into binary object code, and the binary code loaded into memory. Finally, the master model is given a pointer to the loaded instructions and directed to begin execution.
The above-described use of assembly language offers the most realistic simulation. It acts as real code in a real environment, and has the same drawbacks with respect to verification goals. That is, the use of assembly language to control a modeled CPU that interacts with the modeled circuit under test can only control certain aspects of the CPU, such as memory and register operations; it cannot directly manipulate Verilog wires, registers, and time. Furthermore, assembly language is a low level language that typically requires many instructions to perform a single task. In view of the above, an engineer will have a difficult time coding, reading, and debugging assembly language test code.
If the master model is coded in the Verilog HDL language, then the master model may alternatively forego emulation of a real instruction execution cycle, and instead operate (i.e., generate interface signals) in accordance with a list of HDL commands. In effect, this form of master model is just a group of function calls. The functions perform single tasks such as reading data from memory.
HDL is the native language of Verilog and has complete control over the simulation. It can easily manipulate wires, registers, and time. However, HDL offers a limited command set. It does not support string handling, which is useful for generating error, warning, and descriptive messages, and is also needed to parse a command line (presently, command line arguments are accessible only from within the PLI interface). Furthermore, HDL has poor flow control directives. Finally, it does not support the use of data structures and pointers that would otherwise facilitate the emulation of hardware such as first-in-first-out buffers.
A Logic Modeling CPU master reads instructions written in PCL, a language that is similar to the well-known C programming language. PCL includes a subset of C instructions and also provides CPU model specific instructions, such as read.oval-hollow. and write.oval-hollow. to perform memory reads and writes. The language is easier to use than assembly language but still does not allow direct manipulation of Verilog wires, registers, and time. It also lacks string handling, powerful flow control directives, and data structure support.
Finally, using a combination of HDL and Verilog's PLI, the engineer can implement a master model to read a custom-designed simulation language. The language can include any type of instruction devised by the engineer, including those that manipulate Verilog wires, registers, and time. One problem with this approach is that a lot of time is required in order to implement and debug an entire language. Furthermore, the custom-designed language will not be compatible with existing industry standard languages.
In the ideal case, the instructions of a simulation test language will support both bus transactions and "back-door" instructions. Back-door instructions are those that execute transactions in zero simulation time. For example, it may be desired to verify the contents of memory after a direct memory access cycle has been performed by a simulated I/O device. Instead of consuming many bus cycles to read back each data element from the memory (a pointless exercise, since it is not the memory read function that is being tested), a zero simulation time instruction can accomplish this task to efficiently make use of real time.
For the most part, all of the above-described languages support bus transaction instructions. However, most languages do not support back-door instructions.
It has been seen that four types of languages for encoding tests exist. Each language pairs a unique instruction language with a corresponding Verilog master model. Although each of the languages offers some advantages, each is also encumbered with strong disadvantages. No one of the above methods provides a language that has a large command set, allows manipulation of every part of the Verilog environment, is easy to code and debug, and is compatible with other industry software.